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Status of this Memo 


This document specifies an Internet standards track protocol for the 
Internet community, and requests discussion and suggestions for 


improvements. Please refer to the current edition of the "Internet 
Official Protocol Standards" (STD 1) for the standardization state 
and status of this protocol. Distribution of this memo is unlimited. 


Copyright Notice 
Copyright (C) The Internet Society (2003). All Rights Reserved. 
Abstract 


This document defines the procedure to register RTP Payload Formats 
as audio, video or other MIME subtype names. This is useful ina 
text-based format or control protocol to identify the type of an RTP 
transmission. This document also registers all the RTP payload 
formats defined in the RTP Profile for Audio and Video Conferences as 
MIME subtypes. Some of these may also be used for transfer modes 
other than RTP. 
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Introduction 


The MIME registration procedure described in RFC 2048 [1] was 
originally designed for transport of multimedia information via 
asynchronous Internet mail, but the MIME namespace now provides 
identification for other transport modes as well. This document 
defines the procedure to register MIME subtype names for use with the 
Real-time Transport Protocol (RTP), RFC 3550 [2], to identify RTP 
payload formats. 


This document also registers all the RTP payload formats defined in 
the RTP Profile for Audio and Video Conferences, RFC 3551 [3], as 
MIME subtypes under the "audio" and "video" MIME types. 


1. IANA Considerations 
This document registers the following MIME subtypes: 


audio/DVI4 
audio/G722 
audio/G723 
audio/G726-16 
audio/G726-24 
audio/G726-32 
audio/G726-40 
audio/G728 
audio/G729 
audio/G729D 
audio/G729E 
audio/GSM 
audio/GSM-EFR 
audio/L8 
audio/L16 
audio/LPC 
audio/MPA 
audio/PCMA 
audio/PCMU 
audio/QCELP 
audio/RED 
audio/VDVI 
video/BT656 
video/CelB 
video/JPEG 
video/H261 
video/H263 
video/H263-1998 
video/H263-2000 
video/MPV 
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video/MP2T 
video/MP1S 
video/MP2P 
video/BMPEG 
video/nv 


MIME subtype audio/L16 has already been registered via RFC 2586 for 
transports other than RTP. That registration is incorporated here 
and augmented with additional information for RIP transport. 


1.2. Terminology 


The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 
"SHOULD", “SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 
document are to be interpreted as described in RFC 2119 [4] and 
indicate requirement levels for implementations compliant with this 
specification. 


2. Procedure For Registering MIME Types for RTP Payload Types 


Registering an RIP payload type as a MIME type follows the same 
procedures as described in RFC 2048 and uses the registration 
template shown in Section 2.8 of RFC 2048. Some additional 
parameters are required to specify how a particular payload format is 
transported over RTP: 


Published specification 
A description of the encoding and a specification of the 
payload format must be provided, usually by reference to an RTP 
payload format specification RFC. That RFC may be separate, or 
the MIME subtype registration may be incorporated into the 
payload format specification RFC. The payload format 
specification MUST include the RTP timestamp clock rate (or 
multiple rates for audio encodings with multiple sampling 
rates). 


A reference to a further description of the data compression 
format itself should be provided, if available. 


Required parameters 
If the payload format does not have a fixed RTP timestamp clock 
rate, then a "rate" parameter is required to specify the RIP 
timestamp clock rate. A particular payload format may have 
additional required parameters. 
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Optional parameters 
Most audio payload formats can have an optional "channels" 
parameter to specify the number of audio channels included in 
the transmission. Any payload format, but most likely audio 
formats, may also include the optional parameters "ptime", to 
specify the recommended length of time in milliseconds 
represented by the media in a packet, and/or "maxptime" to 
specify the maximum amount of media which can be encapsulated 
in each packet, expressed as time in milliseconds. The "ptime" 
and "maxptime" parameters are defined in the Session 
Description Protocol (SDP) [5]. 


A particular payload format may have additional optional 
parameters. 


Encoding considerations 
The fact that the type can be transferred via RTP MUST be 
noted. 


Depending on whether the type has already been registered for 
transfer with a non-RTP protocol (e.g. MIME mail or http) or not, 
several different cases can occur: 


a) Not yet registered as a MIME type 


A new registration should be constructed using the MIME 
registration template. The registration may specify transfer 
via other means in addition to RTP if that is feasible and 
desired. The encoding considerations must specify how the type 
is transferred via RTP. 


Optional parameters may be defined as needed, and it must be 
clearly stated whether to which mode(s) of transfer the 
parameters apply. 


b) MIME type exists for a non-RTIP protocol 
The encoding considerations of the existing type should be 
changed to indicate that the type can also be transferred via 
RTP. 
RTP-specific parameters may be added, and it must be clearly 


stated that these are only to be used when the media type is 
transmitted via RTP transport. 
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c) Update an existing MIME type for RTP to be used for a non-RTP 
protocol 


The encoding considerations of the existing type should be 
changed to indicate that the type can also be transferred via a 
non-RTP protocol (e.g. SMIP, HTTP). 


Non-RTP-specific parameters can be added, and it must be 
clearly stated that these are only to be used when the media 


type is transmitted via a non-RTP transport. 


3. Mapping to SDP Parameters 


The representation of a MIME media type is specified in the syntax of 
the Content-Type header field in RFC 2045 [6] as follows: 


type "/" subtype *(";" parameter) 


Parameters may be required for a particular type or subtype or they 
may be optional. For media types which represent RIP payload 
formats, the parameters "rate", "channels", "ptime", and "maxptime" 
have general definitions (given above) that may apply across types 
and subtypes. The format for a parameter is specified in RFC 2045 as 


attribute "=" value 
where attribute is the parameter name and the permissible values are 
specified for each parameter. The value may need to be a quoted 
string if it contains any of the special characters listed in RFC 


2045. 


The information carried in the media type string has a specific 


mapping to fields in the Session Description Protocol (SDP) [5], 
which is commonly used to describe RTP sessions. The mapping is as 
follows: 


o The MIME type (e.g., audio) goes in SDP "m=" as the media name. 


o The MIME subtype (payload format) goes in SDP "a=rtpmap" as the 
encoding name. 


o The general (possibly optional) parameters "rate" and 
"Channels" also go in "a=rtpmap" as clock rate and encoding 
parameters, respectively. 


o The general (and optional) parameters "ptime" and "maxptime" go 
in the SDP "a=ptime" and "a=maxptime" attributes, respectively. 
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o Any payload-format-specific parameters go in the SDP "a=fmtp" 
attribute. The set of allowed parameters is defined by the RFC 
that specifies the payload format and MUST NOT be extended by 
the MIME subtype registration without a corresponding revision 
of the payload format specification. The format and syntax of 
these parameters may also be defined by the payload format 
specification, but it is suggested that the parameters be 
copied directly from the MIME media type string as a semicolon 
separated list of parameter=value pairs. For payload formats 
that specify some other syntax for the fmtp parameters, the 
registration of that payload format as a MIME subtype must 
specify what the parameters are in MIME format and how to map 
them to the SDP "a=fmtp" attribute. See Section 4.1.21 for an 
example. 


An example mapping is as follows: 
audio/L16; rate=48000; channels=2; ptime=5; emphasis=50-15 


m=audio 49170 RTP/AVP 97 
a=rtpmap:97 L16/48000/2 

a=fmtp:97 emphasis=50-15 
a=ptime:5 


Note that the payload format (encoding) names defined in the RTP 
Profile are commonly shown in upper case. MIME subtypes are commonly 
shown in lower case. These names are case-insensitive in both 
places. Similarly, parameter names are case-insensitive both in MIME 
types and in the default mapping to the SDP a=fmtp attribute. 


4. Registrations for "Audio/Video Profile" 
In the following sections, all RTP payload formats described in the 
RTP Profile for Audio and Video Conferences, RFC 3551 [3], are 
registered as MIME subtypes. 

4.1. Audio Type Registrations 


The following sections register all of the RTP audio payload types 
defined in RFC 3551 as MIME types. 


For most audio payload formats, the RTP timestamp clock rate is equal 


to the sampling rate. Some payload formats operate only at one fixed 
sampling rate, while others are adjustable. 
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4.1.1. Registration of MIME media type audio/DVI4 
MIME media type name: audio 
MIME subtype name: DVI4 
Required parameters: rate 
The RIP timestamp clock rate, which is equal to the sampling 
rate. The typical rate is 8000, but other rates may be 
specified. 


Optional parameters: ptime, maxptime 


Encoding considerations: 
This type is only defined for transfer via RTP [RFC 3550]. 


Security considerations: See Section 5 of RFC 3555 
Interoperability considerations: none 
Published specification: RFC 3551 


Applications which use this media type: 
Audio and video streaming and conferencing tools. 


Additional information: none 


Person & email address to contact for further information: 
Stephen Casner <casner@acm.org> 


Intended usage: COMMON 


Author/Change controller: 
Stephen Casner 
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4.1.2. Registration of MIME media type audio/G722 
MIME media type name: audio 
MIME subtype name: G722 
Required parameters: None 
Optional parameters: ptime, maxptime 


Encoding considerations: 
This type is only defined for transfer via RTP [RFC 3550]. 


Security considerations: See Section 5 of RFC 3555 
Interoperability considerations: none 
Published specification: RFC 3551 


Applications which use this media type: 
Audio and video streaming and conferencing tools. 


Additional information: none 


Person & email address to contact for further information: 
Stephen Casner <casner@acm.org> 


Intended usage: COMMON 


Author/Change controller: 
Stephen Casner 
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4.1.3. Registration of MIME media type audio/G723 
MIME media type name: audio 
MIME subtype name: G723 
Required parameters: None 


Optional parameters: 
ptime, maxptime 


bitrate: the data rate in kb/s used or preferred for the audio 
bit stream, with permissible values 5.3 or 6.3. If 
unspecified, the bitrate may change from frame to frame as 
indicated inband. 

annexa: indicates that Annex A, voice activity detection, is 
used or preferred. Permissible values are "yes" and "no" 
(without the quotes); "yes" is implied if this parameter is 
omitted. 


Encoding considerations: 
This type is only defined for transfer via RTP [RFC 3550]. 


Security considerations: See Section 5 of RFC 3555 
Interoperability considerations: none 
Published specification: RFC 3551 


Applications which use this media type: 
Audio and video streaming and conferencing tools. 


Additional information: none 


Person & email address to contact for further information: 
Stephen Casner <casner@acm.org> 


Intended usage: COMMON 


Author/Change controller: 
Stephen Casner 
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4.1.4. Registration of MIME media type audio/G726-16 
MIME media type name: audio 
MIME subtype name: G726-16 
Required parameters: None 
Optional parameters: ptime, maxptime 


Encoding considerations: 


July 2003 


This type is only defined for transfer via RTP [RFC 3550]. 


Security considerations: See Section 5 of RFC 3555 
Interoperability considerations: none 
Published specification: RFC 3551 


Applications which use this media type: 
Audio and video streaming and conferencing tools. 


Additional information: none 


Person & email address to contact for further information: 


Stephen Casner <casner@acm.org> 
Intended usage: COMMON 


Author/Change controller: 
Stephen Casner 
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4.1.5. Registration of MIME media type audio/G726-24 
MIME media type name: audio 
MIME subtype name: G726-24 
Required parameters: None 
Optional parameters: ptime, maxptime 


Encoding considerations: 


July 2003 


This type is only defined for transfer via RTP [RFC 3550]. 


Security considerations: See Section 5 of RFC 3555 
Interoperability considerations: none 
Published specification: RFC 3551 


Applications which use this media type: 
Audio and video streaming and conferencing tools. 


Additional information: none 


Person & email address to contact for further information: 


Stephen Casner <casner@acm.org> 
Intended usage: COMMON 


Author/Change controller: 
Stephen Casner 
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4.1.6. Registration of MIME media type audio/G726-32 
MIME media type name: audio 
MIME subtype name: G726-32 
Required parameters: None 
Optional parameters: ptime, maxptime 


Encoding considerations: 


July 2003 


This type is only defined for transfer via RTP [RFC 3550]. 


Security considerations: See Section 5 of RFC 3555 
Interoperability considerations: none 
Published specification: RFC 3551 


Applications which use this media type: 
Audio and video streaming and conferencing tools. 


Additional information: none 


Person & email address to contact for further information: 


Stephen Casner <casner@acm.org> 
Intended usage: COMMON 


Author/Change controller: 
Stephen Casner 
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4.1.7. Registration of MIME media type audio/G726-40 
MIME media type name: audio 
MIME subtype name: G726-40 
Required parameters: None 
Optional parameters: ptime, maxptime 


Encoding considerations: 


July 2003 


This type is only defined for transfer via RTP [RFC 3550]. 


Security considerations: See Section 5 of RFC 3555 
Interoperability considerations: none 
Published specification: RFC 3551 


Applications which use this media type: 
Audio and video streaming and conferencing tools. 


Additional information: none 


Person & email address to contact for further information: 


Stephen Casner <casner@acm.org> 
Intended usage: COMMON 


Author/Change controller: 
Stephen Casner 
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4.1.8. Registration of MIME media type audio/G728 
MIME media type name: audio 
MIME subtype name: G728 
Required parameters: None 
Optional parameters: ptime, maxptime 


Encoding considerations: 
This type is only defined for transfer via RTP [RFC 3550]. 


Security considerations: See Section 5 of RFC 3555 
Interoperability considerations: none 
Published specification: RFC 3551 


Applications which use this media type: 
Audio and video streaming and conferencing tools. 


Additional information: none 


Person & email address to contact for further information: 
Stephen Casner <casner@acm.org> 


Intended usage: COMMON 


Author/Change controller: 
Stephen Casner 
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4.1.9. Registration of MIME media type audio/G729 
MIME media type name: audio 
MIME subtype name: G729 
Required parameters: None 


Optional parameters: 
ptime, maxptime 


July 2003 


annexb: indicates that Annex B, voice activity detection, is 


used or preferred. Permissible values are "yes" and 


"no " 


(without the quotes); "yes" is implied if this parameter is 


omitted. 


Encoding considerations: 


This type is only defined for transfer via RTP [RFC 3550]. 


Security considerations: See Section 5 of RFC 3555 
Interoperability considerations: none 
Published specification: RFC 3551 


Applications which use this media type: 
Audio and video streaming and conferencing tools. 


Additional information: none 


Person & email address to contact for further information: 


Stephen Casner <casner@acm.org> 
Intended usage: COMMON 


Author/Change controller: 
Stephen Casner 
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4.1.10. Registration of MIME media type audio/G729D 
MIME media type name: audio 
MIME subtype name: G729D 
Required parameters: None 


Optional parameters: 
ptime, maxptime 


July 2003 


annexb: indicates that Annex B, voice activity detection, is 


used or preferred. Permissible values are "yes" and 


"no " 


(without the quotes); "yes" is implied if this parameter is 


omitted. 


Encoding considerations: 


This type is only defined for transfer via RTP [RFC 3550]. 


Security considerations: See Section 5 of RFC 3555 
Interoperability considerations: none 
Published specification: RFC 3551 


Applications which use this media type: 
Audio and video streaming and conferencing tools. 


Additional information: none 


Person & email address to contact for further information: 


Stephen Casner <casner@acm.org> 
Intended usage: COMMON 


Author/Change controller: 
Stephen Casner 
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4.1.11. Registration of MIME media type audio/G729E 
MIME media type name: audio 
MIME subtype name: G729E 
Required parameters: None 


Optional parameters: 
ptime, maxptime 


July 2003 


annexb: indicates that Annex B, voice activity detection, is 


used or preferred. Permissible values are "yes" and 


"no " 


(without the quotes); "yes" is implied if this parameter is 


omitted. 


Encoding considerations: 


This type is only defined for transfer via RTP [RFC 3550]. 


Security considerations: See Section 5 of RFC 3555 
Interoperability considerations: none 
Published specification: RFC 3551 


Applications which use this media type: 
Audio and video streaming and conferencing tools. 


Additional information: none 


Person & email address to contact for further information: 


Stephen Casner <casner@acm.org> 
Intended usage: COMMON 


Author/Change controller: 
Stephen Casner 
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4.1.12. Registration of MIME media type audio/GSM 
MIME media type name: audio 
MIME subtype name: GSM 
Required parameters: None 
Optional parameters: ptime, maxptime 


Encoding considerations: 
This type is only defined for transfer via RTP [RFC 3550]. 


Security considerations: See Section 5 of RFC 3555 
Interoperability considerations: none 
Published specification: RFC 3551 


Applications which use this media type: 
Audio and video streaming and conferencing tools. 


Additional information: none 


Person & email address to contact for further information: 
Stephen Casner <casner@acm.org> 


Intended usage: COMMON 


Author/Change controller: 
Stephen Casner 
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4.1.13. Registration of MIME media type audio/GSM-EFR 
MIME media type name: audio 
MIME subtype name: GSM-EFR 
Required parameters: None 
Optional parameters: ptime, maxptime 


Encoding considerations: 


July 2003 


This type is only defined for transfer via RTP [RFC 3550]. 


Security considerations: See Section 5 of RFC 3555 
Interoperability considerations: none 
Published specification: RFC 3551 


Applications which use this media type: 
Audio and video streaming and conferencing tools. 


Additional information: none 


Person & email address to contact for further information: 


Stephen Casner <casner@acm.org> 
Intended usage: COMMON 


Author/Change controller: 
Stephen Casner 
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4.1.14. Registration of MIME media type audio/L8 
MIME media type name: audio 
MIME subtype name: L8 
Required parameters: rate, the RTP timestamp clock rate 
Optional parameters: channels, ptime, maxptime 


Encoding considerations: 


July 2003 


This type is only defined for transfer via RTP [RFC 3550]. 


Security considerations: See Section 5 of RFC 3555 
Interoperability considerations: none 
Published specification: RFC 3551 


Applications which use this media type: 
Audio and video streaming and conferencing tools. 


Additional information: none 


Person & email address to contact for further information: 


Stephen Casner <casner@acm.org> 
Intended usage: COMMON 


Author/Change controller: 
Stephen Casner 
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4.1.15. Registration of MIME media type audio/L16 


MIME subtype audio/L16 has already been registered via RFC 2586 for 
transports other than RTP. That registration is incorporated here 
and augmented with additional information for RTP transport. 


MIME media type name: audio 
MIME subtype name: L16 


Required parameters 
rate: number of samples per second -- For non-RTP transport, 
the permissible values for rate are 8000, 11025, 16000, 22050, 
24000, 32000, 44100, and 48000 samples per second. For RTP 
transport, other values are permissible but the aforementioned 
values are RECOMMENDED. For RTP, the rate parameter indicates 
the RTP timestamp clock rate, which is equal to the sample 
rate. 


Optional parameters 
channels: how many audio streams are interleaved -- defaults 
to 1; stereo would be 2, etc. Interleaving takes place 
between individual two-byte samples. 


emphasis: analog preemphasis applied to the signal before 
quantization. The only emphasis value defined here is 
emphasis=50-15 to indicate the 50/15 microsecond preemphasis 
used with Compact Disks. This parameter MUST be omitted if no 
analog preemphasis was applied. 


channel-order: specifies the sample interleaving order for 
multiple-channel audio streams (see [7] Section 7). 
Permissible values are DV.LRLSRs, DV.LRCS, DV.LRCWo, 
DV.LRLSRsC, DV.LRLSRSCS, DV.LmixRmixTWoQ1Q2, 
DV.LRCWoLsRsLmixRmix, DV.LRCWoLs1RslLls2Rs2, DV.LRCWoLsRsLcRc. 
For interoperation with DV video systems, only a subset of 
these channel combinations is specified for use with 20-bit 
linear encoding in the DV video specification [4]; those are 
DV.LRLsRs, DV.LRCS, DV.LmixRmixTWoQ102. This parameter MUST 
be omitted when the AIFF-C channel order convention (see RFC 
3551) is in use. 


For RTP, ptime: RECOMMENDED duration of each packet in 
milliseconds. 


For RTP, maxptime: maximum duration of each packet in 
milliseconds. 
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Encoding considerations 
Audio data is binary data, and must be encoded for non-binary 
transport; the Base64 encoding is suitable for Email. Note 
that audio data does not compress easily using lossless 
compression. 


This type is also defined for transfer via RTP [RFC 3550]. 


Security considerations 
Audio data is believed to offer no security risks. 
See Section 5 of RFC 3555. 


Interoperability considerations 
This type is compatible with the encoding used in the WAV 
(Microsoft Windows RIFF) and Apple AIFF union types, and with 
the public domain "sox" and "rateconv" programs. 


Published specification 
RFC 2586 for non-RTP transports, RFC 3551 for RTP 


Applications which use this media 
The public domain "sox" and "rateconv" programs accept this 


type. 
1. Magic number(s) : None 
2. File extension(s) : WAV L16 


3. Macintosh file type code : AIFF 


Person to contact for further information 
1. Name : James Salsman 
2. E-mail : jps-Llé6é@bovik.org 


Intended usage 
Common 


It is expected that many audio and speech applications will 
use this type. Already the most popular platforms provide 
this type with the rate=11025 parameter referred to as "radio 
quality speech." 


Author/Change controller 


James Salsman for non-RTP transports. 
Stephen Casner for RTP transport. 
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4.1.16. Registration of MIME media type audio/LPC 
MIME media type name: audio 
MIME subtype name: LPC 
Required parameters: None 
Optional parameters: ptime, maxptime 


Encoding considerations: 
This type is only defined for transfer via RTP [RFC 3550]. 


Security considerations: See Section 5 of RFC 3555 
Interoperability considerations: none 
Published specification: RFC 3551 


Applications which use this media type: 
Audio and video streaming and conferencing tools. 


Additional information: none 


Person & email address to contact for further information: 
Stephen Casner <casner@acm.org> 


Intended usage: COMMON 


Author/Change controller: 
Stephen Casner 
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4.1.17. Registration of MIME media type audio/MPA 
MIME media type name: audio 
MIME subtype name: MPA (MPEG audio) 
Required parameters: None 
Optional parameters: 


layer: which layer of MPEG audio encoding; permissible values 
are; 2p. 3 


samplerate: the rate at which audio is sampled. MPEG-1 audio 
supports sampling rates of 32, 44.1, and 48 kHz; MPEG-2 

supports sampling rates of 16, 22.05 and 24 kHz. This parameter 
is separate from the RTP timestamp clock rate which is always 
90000 Hz for MPA. 


mode: permissible values are "Stereo", "Jjoint_stereo", 
"single_channel", "dual_channel". The "channels" parameter 
does not apply to MPA. It is undefined to put a number of 
channels in the SDP rtpmap attribute for MPA. 

bitrate: the data rate for the audio bit stream. 

ptime: RECOMMENDED duration of each packet in milliseconds. 
maxptime: maximum duration of each packet in milliseconds. 
Parameters which are omitted are left to the encoder to choose 
based on the session bandwidth, configuration information, or 
other constraints. The selected layer as well as the sampling 
rate and mode are indicated in the payload so receivers can 
process the data without these parameters being specified 


externally. 


Encoding considerations: 
This type is only defined for transfer via RTP [RFC 3550]. 


Security considerations: See Section 5 of RFC 3555 
Interoperability considerations: none 
Published specification: RFC 3551 


Applications which use this media type: 
Audio and video streaming and conferencing tools. 
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Additional information: none 


Person & email address to contact for further information: 
Stephen Casner <casner@acm.org> 


Intended usage: COMMON 


Author/Change controller: 
Stephen Casner 


4.1.18. Registration of MIME media type audio/PCMA 


MIME media type name: audio 

MIME subtype name: PCMA 

Required parameters: rate 
The RIP timestamp clock rate, which is equal to the sampling 
rate. The typical rate is 8000, but other rates may be 
specified. 


Optional parameters: channels, ptime, maxptime 


Encoding considerations: 
This type is only defined for transfer via RTP [RFC 3550]. 


Security considerations: See Section 5 of RFC 3555 
Interoperability considerations: none 
Published specification: RFC 3551 


Applications which use this media type: 
Audio and video streaming and conferencing tools. 


Additional information: none 


Person & email address to contact for further information: 
Stephen Casner <casner@acm.org> 


Intended usage: COMMON 


Author/Change controller: 
Stephen Casner 
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4.1.19. Registration of MIME media type audio/PCMU 
MIME media type name: audio 
MIME subtype name: PCMU 
Required parameters: rate 
The RTP timestamp clock rate, which is equal to the sampling 
rate. The typical rate is 8000, but other rates may be 
specified. 


Optional parameters: channels, ptime, maxptime 


Encoding considerations: 
This type is only defined for transfer via RTP [RFC 3550]. 


Security considerations: See Section 5 of RFC 3555 
Interoperability considerations: none 
Published specification: RFC 3551 


Applications which use this media type: 
Audio and video streaming and conferencing tools. 


Additional information: none 


Person & email address to contact for further information: 
Stephen Casner <casner@acm.org> 


Intended usage: COMMON 


Author/Change controller: 
Stephen Casner 
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4.1.20. Registration of MIME media type audio/QCELP 
MIME media type name: audio 
MIME subtype name: QCELP 
Required parameters: None 
Optional parameters: ptime, maxptime 


Encoding considerations: 


July 2003 


This type is only defined for transfer via RTP [RFC 3550]. 


Security considerations: See Section 5 of RFC 3555 
Interoperability considerations: none 
Published specification: RFC 2658 


Applications which use this media type: 
Audio and video streaming and conferencing tools. 


Additional information: none 


Person & email address to contact for further information: 


Stephen Casner <casner@acm.org> 
Intended usage: COMMON 


Author/Change controller: 
Stephen Casner 
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4.1.21. Registration of MIME media type audio/RED 
MIME media type name: audio 
MIME subtype name: RED 


Required parameters: 
pt: a comma-separated list of RTP payload types. Because 
comma is a special character, the list must be a quoted-string 
(enclosed in double quotes). For static payload types, each 
list element is simply the type number. For dynamic payload 
types, each list element is a mapping of the dynamic payload 
type number to an embedded MIME content-type specification for 
the payload format corresponding to the dynamic payload type. 
The format of the mapping is: 


dynamic-—payload-type "=" content-type 


If the content-type string includes a comma, then the 
content-type string MUST be a quoted-string. If the content- 
type string does not include a comma, it MAY still be quoted. 
Since it is part of the list which must itself be a quoted- 
string, that means the quotation marks MUST be quoted with 
backslash quoting as specified in RFC 2045. If the content- 
type string itself contains a quoted-string, then the 
requirement for backslash quoting is recursively applied. To 
specify the audio/RED payload format in SDP, the pt parameter 
is mapped to an a=fmtp attribute by eliminating the parameter 
name (pt) and changing the commas to slashes. For example, 
“pt="0,5"" maps to ’a=fmtp:99 0/5’. A more complicated 
example, with a dynamic payload type, is: 


pt = "0, 103 = \"audio/G729D; annexb=yes\" " 
m=audio 49170 RTP/AVP 99 0 103 

a=rtpmap:99 RED/8000 

a=fmtp:99 0/103 

a=rtpmap:103 G729D/8000 

a=fmtp:103 annexb=yes 


Optional parameters: ptime, maxptime 


Encoding considerations: 
This type is only defined for transfer via RTP [RFC 3550]. 


Security considerations: See Section 5 of RFC 3555 


Interoperability considerations: none 
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Published specification: RFC 2198 


Applications which use this media type: 
Audio and video streaming and conferencing tools. 


Additional information: none 


Person & email address to contact for further information: 
Stephen Casner <casner@acm.org> 


Intended usage: COMMON 


Author/Change controller: 
Stephen Casner 


4.1.22. Registration of MIME media type audio/VDVI 
MIME media type name: audio 
MIME subtype name: VDVI 
Required parameters: None 
Optional parameters: ptime, maxptime 


Encoding considerations: 
This type is only defined for transfer via RTP [RFC 3550]. 


Security considerations: See Section 5 of RFC 3555 
Interoperability considerations: none 
Published specification: RFC 3551 


Applications which use this media type: 
Audio and video streaming and conferencing tools. 


Additional information: none 


Person & email address to contact for further information: 
Stephen Casner <casner@acm.org> 


Intended usage: COMMON 


Author/Change controller: 
Stephen Casner 
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4.2. Video Type Registrations 
For all of the video payload formats registered here, the RIP 
timestamp clock rate is always 90000 Hz, so the "rate" parameter is 
not applicable. Likewise, the "channel" parameter is not used with 
video, and while "ptime" and "maxptime" could be used with video, 
they typically are not. 

4.2.1. Registration of MIME media type video/BT656 
MIME media type name: video 
MIME subtype name: BT656 
Required parameters: None 


Optional parameters: None 


Encoding considerations: 
This type is only defined for transfer via RTP [RFC 3550]. 


Security considerations: See Section 5 of RFC 3555 
Interoperability considerations: none 
Published specification: RFC 2431 


Applications which use this media type: 
Audio and video streaming and conferencing tools. 


Additional information: none 


Person & email address to contact for further information: 
Stephen Casner <casner@acm.org> 


Intended usage: COMMON 


Author/Change controller: 
Stephen Casner 
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4.2.2. Registration of MIME media type video/CelB 
MIME media type name: video 
MIME subtype name: CelB 
Required parameters: None 
Optional parameters: None 


Encoding considerations: 
This type is only defined for transfer via RTP [RFC 3550]. 


Security considerations: See Section 5 of RFC 3555 
Interoperability considerations: none 
Published specification: RFC 2029 


Applications which use this media type: 
Audio and video streaming and conferencing tools. 


Additional information: none 


Person & email address to contact for further information: 
Stephen Casner <casner@acm.org> 


Intended usage: COMMON 


Author/Change controller: 
Stephen Casner 
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4.2.3. Registration of MIME media type video/JPEG 
MIME media type name: video 
MIME subtype name: JPEG 
Required parameters: None 
Optional parameters: None 


Encoding considerations: 
This type is only defined for transfer via RTP [RFC 3550]. 


Security considerations: See Section 5 of RFC 3555 
Interoperability considerations: none 
Published specification: RFC 2435 


Applications which use this media type: 
Audio and video streaming and conferencing tools. 


Additional information: none 


Person & email address to contact for further information: 
Stephen Casner <casner@acm.org> 


Intended usage: COMMON 


Author/Change controller: 
Stephen Casner 
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4.2.4. Registration of MIME media type video/H261 
MIME media type name: video 
MIME subtype name: H261 
Required parameters: None 
Optional parameters: None 


Encoding considerations: 
This type is only defined for transfer via RTP [RFC 3550]. 


Security considerations: See Section 5 of RFC 3555 
Interoperability considerations: none 
Published specification: RFC 2032 


Applications which use this media type: 
Audio and video streaming and conferencing tools. 


Additional information: none 


Person & email address to contact for further information: 
Stephen Casner <casner@acm.org> 


Intended usage: COMMON 


Author/Change controller: 
Stephen Casner 
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4.2.5. Registration of MIME media type video/H263 
MIME media type name: video 
MIME subtype name: H263 
Required parameters: None 
Optional parameters: None 


Encoding considerations: 
This type is only defined for transfer via RTP [RFC 3550]. 


Security considerations: See Section 5 of RFC 3555 
Interoperability considerations: none 
Published specification: RFC 2190 


Applications which use this media type: 
Audio and video streaming and conferencing tools. 


Additional information: none 


Person & email address to contact for further information: 
Stephen Casner <casner@acm.org> 


Intended usage: COMMON 


Author/Change controller: 
Stephen Casner 
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4.2.6. Registration of MIME media type video/H263-1998 
MIME media type name: video 
MIME subtype name: H263-1998 
Required parameters: None 
Optional parameters: None 


Encoding considerations: 


July 2003 


This type is only defined for transfer via RTP [RFC 3550]. 


Security considerations: See Section 5 of RFC 3555 
Interoperability considerations: none 
Published specification: RFC 2429 


Applications which use this media type: 
Audio and video streaming and conferencing tools. 


Additional information: none 


Person & email address to contact for further information: 


Stephen Casner <casner@acm.org> 
Intended usage: COMMON 


Author/Change controller: 
Stephen Casner 
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.2.7. Registration of MIME media type video/H263-2000 

MIME media type name: video 

MIME subtype name: H263-2000 

Required parameters: None 

Optional parameters: 
profile: H.263 profile number, in the range 0 through 10, 
specifying the supported H.263 annexes/subparts. 
level: Level of bitstream operation, in the range 0 through 
100, specifying the level of computational complexity of the 


decoding process. 


Encoding considerations: 
This type is only defined for transfer via RTP [RFC 3550]. 


Security considerations: See Section 5 of RFC 3555 
Interoperability considerations: none 


Published specification: RFC 2429 
The specific values for the profile and level parameters and 
their meaning are defined in Annex X of ITU-T Recommendation 
H.263, "Video coding for low bit rate communication". Note 
that the RTP payload format for H263-2000 is the same as for 
H263-1998, but additional annexes/subparts are specified along 
with the profiles and levels. 


Applications which use this media type: 
Audio and video streaming and conferencing tools. 


Additional information: none 


Person & email address to contact for further information: 
Stephen Casner <casner@acm.org> 


Intended usage: COMMON 


Author/Change controller: 
Stephen Casner 
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4.2.8. Registration of MIME media type video/MPV 
MIME media type name: video 


MIME subtype name: MPV 
MPEG-1 or -2 Elementary Streams 


Required parameters: None 

Optional parameters: 
type: the type of MPEG video, from the set "mpegl", 
"mpeg2-halfdl", or "mpeg2-fulld1i". The default is "mpegl". 
The mapping to a=fmtp is identity. 


Encoding considerations: 
This type is only defined for transfer via RTP [RFC 3550]. 


Security considerations: See Section 5 of RFC 3555 
Interoperability considerations: none 
Published specification: RFC 2250 


Applications which use this media type: 
Audio and video streaming and conferencing tools. 


Additional information: none 


Person & email address to contact for further information: 
Stephen Casner <casner@acm.org> 


Intended usage: COMMON 


Author/Change controller: 
Stephen Casner 
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4.2.9. Registration of MIME media type video/MP2T 
MIME media type name: video 


MIME subtype name: MP2T 
MPEG-2 Transport Streams 


Required parameters: None 
Optional parameters: None 


Encoding considerations: 


July 2003 


This type is only defined for transfer via RTP [RFC 3550]. 


Security considerations: See Section 5 of RFC 3555 
Interoperability considerations: none 
Published specification: RFC 2250 


Applications which use this media type: 
Audio and video streaming and conferencing tools. 


Additional information: none 


Person & email address to contact for further information: 


Stephen Casner <casner@acm.org> 
Intended usage: COMMON 


Author/Change controller: 
Stephen Casner 
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4.2.10. Registration of MIME media type video/MP1S 
MIME media type name: video 


MIME subtype name: MP1S 
MPEG-1 Systems Streams 


Required parameters: None 
Optional parameters: None 


Encoding considerations: 


July 2003 


This type is only defined for transfer via RTP [RFC 3550]. 


Security considerations: See Section 5 of RFC 3555 
Interoperability considerations: none 
Published specification: RFC 2250 


Applications which use this media type: 
Audio and video streaming and conferencing tools. 


Additional information: none 


Person & email address to contact for further information: 


Stephen Casner <casner@acm.org> 
Intended usage: COMMON 


Author/Change controller: 
Stephen Casner 
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4.2.11. Registration of MIME media type video/MP2P 
MIME media type name: video 


MIME subtype name: MP2P 
MPEG-2 Program Streams 


Required parameters: None 
Optional parameters: None 


Encoding considerations: 


July 2003 


This type is only defined for transfer via RTP [RFC 3550]. 


Security considerations: See Section 5 of RFC 3555 
Interoperability considerations: none 
Published specification: RFC 2250 


Applications which use this media type: 
Audio and video streaming and conferencing tools. 


Additional information: none 


Person & email address to contact for further information: 


Stephen Casner <casner@acm.org> 
Intended usage: COMMON 


Author/Change controller: 
Stephen Casner 
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4.2.12. Registration of MIME media type video/BMPEG 
MIME media type name: video 
MIME subtype name: BMPEG 
Required parameters: None 
Optional parameters: None 


Encoding considerations: 


July 2003 


This type is only defined for transfer via RTP [RFC 3550]. 


Security considerations: See Section 5 of RFC 3555 
Interoperability considerations: none 
Published specification: RFC 2343 


Applications which use this media type: 
Audio and video streaming and conferencing tools. 


Additional information: none 


Person & email address to contact for further information: 


Stephen Casner <casner@acm.org> 
Intended usage: COMMON 


Author/Change controller: 
Stephen Casner 
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4.2.13. Registration of MIME media type video/nv 
MIME media type name: video 
MIME subtype name: nv 
Required parameters: None 
Optional parameters: None 


Encoding considerations: 
This type is only defined for transfer via RTP [RFC 3550]. 


Security considerations: See Section 5 of RFC 3555 
Interoperability considerations: none 
Published specification: RFC 3551 


Applications which use this media type: 
Audio and video streaming and conferencing tools. 


Additional information: none 


Person & email address to contact for further information: 
Stephen Casner <casner@acm.org> 


Intended usage: COMMON 


Author/Change controller: 
Stephen Casner 


5. Security Considerations 


The MIME subtype registration procedure specified in this memo does 
not impose any security considerations on its own. This memo also 
contains several MIME type registrations. The registrations 
themselves do not impose security risks, but some may state security 
considerations specific to the particular registration. 


Several audio and video encodings are perfect for hiding data using 
steganography. 


The RTP specification, RFC 3550, provides security considerations for 


the transport of audio and video data over RTP, including the use of 
encryption where confidentiality is required. 
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This document and translations of it may be copied and furnished to 
others, and derivative works that comment on or otherwise explain it 
or assist in its implementation may be prepared, copied, published 
and distributed, in whole or in part, without restriction of any 
kind, provided that the above copyright notice and this paragraph are 
included on all such copies and derivative works. However, this 
document itself may not be modified in any way, such as by removing 
the copyright notice or references to the Internet Society or other 
Internet organizations, except as needed for the purpose of 
developing Internet standards in which case the procedures for 
copyrights defined in the Internet Standards process must be 
followed, or as required to translate it into languages other than 
English. 


The limited permissions granted above are perpetual and will not be 
revoked by the Internet Society or its successors or assigns. 


This document and the information contained herein is provided on an 
"AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING 
TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING 
BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION 
HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF 
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